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(£) Creating and controlling lighting designs. 



© Disclosed is a modelling and control system for creating lighting designs off-line and for controlling on-line 
the operation of the actual lighting systems producing those designs. Using a programmable computer, the 
modelling system prompts inputs by the designerprogrammer describing model objects and their parameters 
including stage dimensions, set pieces and their locations, performers and their positions, trusses, lamps and 
their parameters such as color, focus, intensity, beam edge, and the relations among the objects. The sytem 
computes the resutant lighting scenes, organized as cues and arranged and formatted to be compatible with 
actual lighting controller usage. The system displays the model environment in such a way as to facilitate the 
modelling operation and its results. It also also generates a variety of spreadsheets for use by the designer. 
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BACKGROUND-FIELD OF THE INVENTION 
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The present invention relates to a system for creating lighting designs and for controlling the operation 
of lighting systems used in presenting those designs. Involved are both the off-line modelling of the lighting 
design including its environment and dynamic behaviour, and the on-line implementation of the design 
through control of the lighting system. 
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BACKGROUND AND DISCUSSION OF PRIOR ART 

Modern lighting projectors, such as those used in stage lighting applications, typically allow for the 
variation of many lighting parameters in order to achieve various lighting effects. Conventional lighting 
instruments offer variable control of the intensity of the light as well as its color (hue and saturation), 
direction (sometimes referred to as focus) and beam size, shape and sharpness. Pattern projections 
accomplished with "gobos" are also employed for certain effects. ^ ^ 

Directing the beam of a variable multi-parameter lighting instrument, such as the VL2B " , VL3 . or 
VL4" M models of automated lights manufactured by Vari-Ute. Inc., to a desired target or site is obtained by 
pivoting the light assembly within a "yoke" to achieve desired elevation or tilt, and by rotating the yoke to 
"pan" the beam. 

Intensity is controlled in these lighting instruments by adjusting lamp excitation or using a mechanical 
"dowser" such as an iris. Color is achieved with adjustable dichroic fitters wh.ie beam diameter and degree 
of sharpness-diffusion are established by iris or lens systems and diffusers. 

A typical lighting system consists of an array of lights such as these in communication with a 
centralized computer-based lighting controller operated from a console. The console can selectively access 
individual or groups of lights and by the adjustment of console controls, selected lights may be man.pulated 
to direct each light to its proper target and to adjust the beam parameters, that control the characteristics of 

the lights- . , 

With many automated lights each offering programmable color, beam size, intensity, edge, and gobo 
pattern, as well as pan and tilt, and with many systems incorporating many scores of such lights located in 
variable positions, it is apparent that the lighting designer is confronted with a daunting and time-consuming 
30 task. 

In stage lighting this task typically involves the creation during rehearsal of a series of lighting scenes or 
cues in accordance with the desired dramatic effects sought to be achieved. Each scene is initially 
designed using the console controls. (Ught placement may also be involved.) Once the desired lighting 
effect is achieved in a setup or manual control mode, the console operator can store the parameters in 
35 computer memory as a cue for later access. The cue defines all of the lighting attributes such as pan. tilt, 
color, and beam size for each of the lights to be used in that cue. 

Since the lighting designer needs to create lighting effects in the context of the performance and to 
observe the overall lighting effects as he varies each parameter, the traditional method of programming 
automated lighting systems requires use of the theatre, the presence of the cast and crew, and the entire 
40 lighting system, including all of the lights and the console as set up in the theater. While this on-line 
programming method is effective in creating the desired lighting production, it is a time consuming and 
costly process. 

Significant cost savings could be experienced if the programming process or at least a significant part 
of it could be carried out without the need for cast, crew, theatre and system. This is true whether a 
45 production is to be designed from scratch, or where it has to be adapted to a new venue, as in the case of 
tours. In both cases, off-line programming also permits better use of on-line final programming to perfect 
the lighting production. 

In response to these needs, a number of computer-based systems with graphics capabilities have been 
developed to provide off-line programming of automated lighting systems. These graphics systems are 
so designed to partially simulate on a computer screen or other display, what certain real lighting effects will 
look like. 

The "Starlite" system developed by Tasco, Ltd. of London simulates to a degree the overall lighting 
effect as the programmer adjusts the parameter data. The control console of the Tasco system incorporates 
a computer with a graphics display for programming the lights and simulating their functions. However, the 
55 system does not provide the ability to translate positional information of the lights and targets into cue data 
(pan and tilt values) for the lights. A similar product has been developed by "Joan Collins Associates", 953 
N. Highland, Los Angeles. CA, USA. 

It should also be recognized that an off-line computer-based simulation of theatre lighting is inherently 
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limited. Consequently, to be truly effective and affordable, the modeling must involve uncomplicated, 
preferably intuitive tasks; and it must invoke fairly simple instrumentalities which nevertheless are suffi- 
ciently revealing or suggestive to enable the designer to visualize the real effect and the states or values of 
the variables contributing to that effect. Current systems are deficient in these respects. 

Ideally, the system should also simulate the console controls to avoid the need for mastering new 
control/effect relationship. 

It is accordingly an object of the invention to provide an improved lighting design instrument which 
permits off-line creation of lighting designs and thereby reduces dependence on the performers, the theatre 
and the lighting equipment. 

A further object of the invention is to provide an instrument which facilitates the lighting designer's 
visualization of various lighting effects without the need to access the actual lighting equipment. 

Still another object of the invention is to present the user with both schematic and realistic graphical 
displays, thereby allowing the user to eliminate representations of model data which are not of interest and 
permitting the use of low resolution or monochrome displays. 

It is yet another object of the invention to provide off-line programming of lighting productions which 
can be simply and rapidly integrated into the actual lighting equipment system. 

Yet another object of the invention is to provide an instrument for off-line creation of lighting productions 
which can be implemented with a relatively inexpensive computer system and which nevertheless com- 
putes and displays revealing simulations of lighting parameters. 

A still further object of the invention is to provide an off-line lighting show design tool the output of 
which can be used to directly control lighting instruments. It is also an object to provide the output in a form 
permitting real time rendering of the lighting design. 

Another object is to duplicate the control functions of the automated lighting console, allowing the 
modelling system to be used to directly control the luminaires in a situation where the effects of operator 
actions on the luminaires cannot be directly observed by the operator either from the modelling system or 
console location. 

Still another object of the invention is to. provide an off-line lighting design programming tool which can 
symbolize and simulate complex lighting relationships in a simple, uncluttered and revealing manner and 
without excessive response time. 

It is also an object of the invention to provide such a programming instrument wherein there is 
produced a variety of displays suited to the varying needs of the designer. 

Another object of the invention is to provide an off-line modelling system for a lighting set in which 
prompts for the user bear an analogous relationship to actual console configurations. 

Yet another object of the invention is to provide an off-line modelling instrument for lighting productions 
which offers the user a choice of methods in specifying model data, and in which menus and dialog boxes 
facilitate use of the instrument. By embedding in the system terms and notations familiar to the lighting 
designer, and producing the customary actions associated with them, the user is able to communicate with 
the system using the same vocabulary and achieving the same results as would be the case with a human 
rather than machine lighting designer assistant. 

Further objects of the invention are to provide an off-line modelling system for lighting designs in which 
a mathematically correct three dimensional model of the performers, the set, the trussing and the luminaires 
of the show is computed and displayed; in which pan and tilt values can be calculated in terms of target 
position; in which model elements are automatically adjusted when related elements are changed, and in 
which updating and revising is simply accomplished. 

SUMMARY OF THE INVENTION 

In the implementation of the invention, a system is provided for modelling a lighting production 
including the characteristics of the production site and the lighting scenes produced by the lighting console 
and the lighting instruments without requiring access to the site and instruments. The system utilizes a 
computer having data entry means, a processor, storage means, a monitor and a graphics generating 
program. The modelling system further includes: 
(1) means for receiving data: 

(a) describing relevant parameters of the lighting site including lighting targets; 

(b) identifying the selection of the lighting instruments to be operational in the production of the 
lighting designs; 

(c) describing the location of the selected lighting instruments; 

(d) describing values of the lighting parameters associated with each of said selected lighting 
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instruments; 

(2) means for computing from the site, light selection, light location and value data, mathematically 
correct three dimensional representations of the desired aggregate lighting designs: 

(3) means for displaying certain of these representations on the monitor; and 

5 (4) means for configuring the results of the computations in a form suitable for ultimate use by said 
actual lighting instruments. 
According to other features of the invention; 

I . The data receiving means include means displayed on the monitor for prompting the entry of valid 
data. 

io 2. Means are included for computing the relationships among the received data such that changes in 
certain of the data produce related changes in data dependent thereon. 

3. Also provided are means for generating at least one spreadsheet generally conforming to the type 
employed by a lighting designer in describing the actual lighting production. 

4. The computing of scene representations includes means for simultaneously generating and displaying 
/5 views of the lighting scenes from different perspectives. 

5. The scene display is generated such that the contributions of the site, light selection, light location and 
light parameter values are readily discernible. 

6. The modelling includes the generation of pan and tilt values as a function of lighting instrument 
location, orientation and target coordinates. 

20 7. The components of the site parameters and lighting are organized on a hierarchical basis. 

8. The modelling process is materially enhanced by generating menus, dialog boxes and icons to 
facilitate entering of valid data in valid sequences. 

9. The modelling process organizes the lighting scene parameters as cues which can be stored and 
recalled. 

25 10. The lighting parameters can be specified in terms of target positions and, in the case of beam 
positioning, the computing system will automatically compute the required pan and tilt. 

I I . Target volumes can also be represented in the model as objects and can be moved and sized 
producing corresponding adjustments in related objects and attributes. 

12. The modelling system is adapted to be in bidirectional communication with the console permitting 
30 the exchange of data and the sharing of roles. 

13. The modelling system includes means for specifying the relationship between model objects. 

14. Dynamic aspects of the lighting scenes can be modelled and simulated. 

From the process point of view, the invention can be summarized as a method for modelling a lighting 
production including the production site and the lighting designs produced by the lighting console and 
35 lighting instruments. The modelling method employes a computing system having a graphic display 
program, data entry means, data processing means, and a monitor. The method comprises the steps of 
(1) entering data into the computing system describing 

(a) relevant characteristics of the lighting site; 

(b) identifying the lighting instruments to be involved in a scene; 

40 (2) generating a display on the monitor representative of the described site; 

(3) entering in the computing system, data related to the positional relationship of the selected 
instruments to the lighting site; 

(4) generating on the monitor a display of the site with the selected instruments showing the positions 
thereof; 

45 (5) entering in the computing system, data describing the lighting parameters of each of the selected 
lighting instruments including, where desired, lighting beam color and beam direction; 

(6) generating for evaluation a display on the monitor simulating the aggregate lighting effects produced 
by the site, the lighting instrument selection, the positioning and the parameter adjustments; and 

(7) repeating prior steps as necessary until a desired display is achieved. 

50 

BRIEF DESCRIPTION OF DRAWINGS 

A more complete understanding of the present invention may be had by reference to the following 
Detailed Description with the accompanying drawings, wherein: 
55 Figure 1 is a schematic block diagram illustrating components of the design instrument and its 
association with a lighting system; 

Figures 2A through 2G display a series of monitor screens and associated menus; 
Figure 3 is a view of the monitor screen showing the objects palette; 
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Figures 4a and 4b are views of model data displayed in a spreadsheet format; 
Figures 5a and 5b illustrate other spreadsheet formats for the model data; 
Figures 6, 7, and 8 illustrate the monitor screen and various manipulation dialogs: 
Figure 9 is a view of the monitor screen showing the tools palette; 

Figures 10A through 10C are views of the monitor screens showing various object selections; 
Figures 1 1 A through 1 1C are views of the monitor display illustrating other selection activities; 
Figures 12 and 13 are diagramatic views of a luminaire illustrating the coordinate axes and angle 
specifying conventions; 

Figures 14 through 17 and Figures 18A, 18B and 18C describe processing steps used in computing 
various lamp positions; 

Figure 19 shows the monitor display screen with the cue store and recall palette; and 
Figure 20 shows the monitor display with an actual lighting scene simulated thereon. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

Certain aspects of the invention are illustrated in Figure 1 where a computing system 20 is displayed for 
modelling the lighting production eventually to be produced by the actual lighting system 100. The latter 
includes a lighting console 110 such as the ARTISAN™ or MINI-ARTISAN ' M marketed by Vari-Lite, Inc., 
and a network of lamps which may for example be various combinations of the models VL2, VL2B, VL3 and 
VL4 previously referenced. 

The lighting controller may be of the type associated with the Vari-Lite VL200 series lighting system 
and portions of the controller may also be configured as described in United States Patent No. 4.980,806, 
issued to Taylor and Walsh on December 25. 1990. 

The computing system 20 is a general purpose computer running under the graphic system described 
hereinafter. The preferred computer model is a Apple Macintosh II fx. It includes a microprocessor, RAM, 
ROM. storage and interfaces with the user via mouse 28 and keyboard 30. A modem for communication is 
also provided and data can be printed on the hard copy printer. 

To facilitate an understanding of the implementation of the invention, certain general factors of the 
illustrated embodiments are first described. The design includes a modelling system and a method for 
modelling, programming, and simulating the functions of an automated lighting system such as 100 having 
variable multi-parameter lighting features. The modelling system and method may be used to write lighting 
cues in advance. 

Using the general purpose computer 20 embodying the graphics generating system and software the 
programmer designer can develop a working model of a lighting system configuration and its surrounding 
environment. The programmer defines the spatial environment, e.g. the theatre or arena, in which' the 
lighting equipment will be used. In addition, the programmer defines each of the elements that comprise the 
lighting system, stage environment and targets to be illuminated. Using the modelling software to generate 
a graphical display of the lighting system on monitor 24, the system is capable of creating and manipulating 
the defined objects. 

With the modelling system of the present invention, all that is required to develop the model is 
knowledge of the dimensions and characteristics of the arena and stage environments and a determination 
of the number, type, and placement of the lights to be utilized. This can be done in advance without 
entering the arena or hanging any lights. 

Once the programmer has developed the basic model by defining the positional relationship of each of 
these elements with respect to other elements in a universal frame of reference, the modelling system 
provides for the graphical creation and manipulation of show objects and their associated attributes in three 
dimensions on the two dimensional display such as screen 24. 

The programmer defines positional and characteristic information for each element in the model by 
communicating interactively with the modelling system using the mouse 28, keyboard 30, cursor 34 and 
other screen objects including icons 35, menus 36 and model objects 37. 

. Cue parameter data may be written by identifying the lights to be assigned, their shape and color, and 
the position of the associated targets to be illuminated. The cue parameter data may include data 
representing other desired beam characteristics. 

After the programmer has obtained the desired lighting effect by defining the beam characteristics and 
associating the necessary lights with their corresponding targets, the system can compute, if necessary, the 
required pan and tilt values for each light so that it is focussed on the desired target. The programmer can 
define the pan and tilt values either by specifying absolute values for these parameters (thus, not requiring 
a pan and tilt computation) or he can associate the lights with their targets. When a light is associated with 
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its target, the pan and tilt values are computed by the modelling system. This computation involves 
retrieving, from a look-up table, the previously defined location of the lights and their targets in free space. 

In addition to writing cue information initially, the programming instrument may be utilized to update or 
revise the stored parameter data. These changes are required, for example, when there is a new 
5 performance venue, or when a new choreography in the performance places the performers at different 
places than had been anticipated. Regardless of the reason for the change, these new values must be 
reflected in stored cue data. In previous programming methods this was a time-consuming and complex 
task. 

Such updates of lighting cues are accomplished in an easy and efficient manner. If any parameter value 
jo changes, such as the position of a light source or target, other parameter data in the corresponding cue or 
group of cues may be revised by merely updating the model cue. This updating is performed interactively. 
The new parameter data is computed based on the updated information. 

The modelling system additionally serves to simulate the functions of the lighting system. The display 
monitor 24 of the modelling computer 20 is utilized to display various graphical representations of the 
15 stored parameter data. In this manner, the programmer can observe the effects of each parameter variation. 

The graphical representation of the modelling system removes the approximation and guess work from 
advance programming. As each parameter is varied, the programmer can see the effect it has on the entire 
lighting system, previewing the behavior of the entire automated lighting system as if it was set-up in a 
performance venue. 

20 The modelling system also displays the configuration of each lighting instrument in any given scene 
(cue) in a number of ways. The display includes: a graphical representation of the lighting instruments 
conforming to the overall parameter data; a listing of the numerical values for one or more parameters 
comprising the configuration of the lighting system; a display of any given scene at random; or scenes 
visualizing the lighting system as the programmer steps through any given sequence of scenes or series of 

25 cues. 

The modelling system can simulate the effects obtained by activating a chase {a timed, repeating 
sequence of cues) at the console by producing a graphical representation of the model objects conforming 
to each of the cues in the chase. These images are then displayed according to the inter-cue timing stored 
in the chase specification. 

30 The transition from one cue to another can likewise be simulated by generating the intermediate pan 
and tilt settings through which the tuminaires pass during the transition, producing graphical representations 
of the model in those intermediate states and displaying those images rapidly to create an animation-tike 
effect of motion. 

Using enhancements, the modelling system can generate a three-dimensional photorealistic image of 
35 modelled scenes. Also, by executing through a series of stored cue data, a sequence of images can be 
shown in rapid succession to produce the illusion of moving images. This allows the user to visualize almost 
exactly what the show will took like. 

The modelling system includes modes which can duplicate the features and functions of the control 
console in the set up of the parameters of the lighting fixtures, the storage of the desired values as cues. 
40 and the recall of the stored cue data to produce the previously designed lighting effects. 

The lighting designer programmer is provided with the ability to select an arbitrary number of symbolic 
representations that are the building blocks of the model. These building blocks are used by the 
programmer to develop the model. When the building blocks that represent the stage, setpieces, targets, 
and trusses are selected, the programmer is prompted to specify the dimensions, support, location and 
45 rotation of the object to be placed within the model. Additionally, when lighting instruments to be added to 
the model are selected, the programmer is prompted to specify the channel number, support, location, and 
hanging orientation of the light. The process can be iterative; the modelling system permits the programmer 
to go back and modify the parameters for any object that he or she has defined in the model. 

50 INTERACTION OF MODELLING SYSTEM WITH ACTUAL LIGHTING SYSTEM 

Four modes of interaction between the modelling system and the actual lighting system are disclosed 
herein. 

In one mode of interaction, the modelling system is independent and off-line from the actual lighting 
55 system. After the programmer completes the modelling and programming stages, he downloads the 
developed parameter data to the control console of the actual lighting system by data transfer means. 

tn another mode of interaction, the modelling system interactively and bidirectionaily communicates with 
the control console of the actual lighting system. In this mode, activity in the modelling system is 

6 
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communicated and reflected in the console and vice-versa. 

In the third alternative mode of interaction, the modelling system actually replaces the conventional 
control console in the control of cue set-up, store and recall. All of the functions of the console are then 
performed by the modelling system. 

Alternatively, the functions of the modelling system can be performed by the control console itself. In 
the fourth mode of interaction, the modelling system replaces the lights in the actual system, responding to 
the controls of the actual console as the lights would. The effect of the user's manipulation of the console 
controls is reflected in the display of the modelling system. 

GRAPHICAL VIEW OF THE MODEL 

The modelling system of the present invention includes a graphical user interface to interact with the 
programmer. In general; the preferred interface follows the guidelines designated in Human Interface 
Guidelines: The Apple Desktop Interface. ISBN 0-201-17753-6 . The interface presents the programmer with 
a graphical view of the model that is a clear, simple, and uncluttered representation of the current state of 
the objects in the model. 

Lighting instruments or other objects can be created, modified and deleted in the graphical view of the 
model. The model objects can be displayed utilizing symbols such as "spheres" for the luminaires. blocks 
for the stage performers, and "rods" for the light beams and trusses. These tasks are performed by the 
programmer, preferably by means of executing menu-driven commands. These functions will be addressed 
in greater detail below. 

The modelling is carried out with the aid of a programmable general purpose computer such as shown 
in Figure 1. A preferred model is the Apple Macintosh II fx. Computer 20 houses the usual complement of a 
processor. ROM memory, drives, busses and control circuits and the modelling system. ■■ 

A typical graphical input device 28 such as a mouse, joystick, tracker ball, or light pen, together with the 
menu system and cursor 34. allows the programmer to interact with computer 20. Mouse 28 is the preferred 
graphical input device for pointing to information on display monitor 24. Alphanumeric keyboard 30 provides 
the usual functions and also serves as an alternative data entry means. 

In the preferred embodiment of the present invention, menus are utilized to allow the programmer to 
efficiently choose an item to be incorporated or updated in the model, or to alter the operating mode of the 
system. The menus are also utilized to present to the programmer only the legitimate alternatives available, 
thereby precluding invalid choices. The menus also ameliorate the need to remember command names and 
give the programmer an overview of all of the alternatives. 

Fig. 2a shows a typical graphical display of a lighting system on display monitor 24. A "menu bar " 38 
lists the names of typical pull-down menus 44 a - g, from which the programmer may select commands' as 
shown in Figs. 2a -2g. When the programmer selects a menu to be displayed from the "menu bar" 38. 
alternative commands are presented for further selection. The selection process and the individual pull- 
down menus 42 a- g are discussed in greater detail below. 

As the programmer builds the graphical model that represents the lighting system and surrounding 
environment a corresponding master data base is created and stored in the memory of computer 20. The 
master data base stores the parameters and attributes that define the objects that are represented in the 
model. As the programmer adds an object to the model, a record for that object is created and stored in the 
master data base. As discussed below, each record has a field for each of the attributes of the object that 
need to be defined during the modelling and programming process. 

The image that is seen on display 24 as the programmer builds the model through an interactive 
graphics process is stored in the underlying master data base in digital memory as a matrix of values. The 
screen image is stored in a frame buffer as a pattern of binary numbers representing an array of picture 
elements (pixels). As changes are graphically made on display 24, the records created in the digital 
memory are modified to represent the current state of the graphical model. 

As the programmer models and programs the lighting system, monitor 24 displays a view of the lighting 
system and stage environment and shows the programmer the results of adjustments to the lighting 
parameters. The programmer can observe the effects of changes in color, pan, tilt, beam size, edge, and 
intensity on the overall lighting effect. Other effects, e.g., gobo selection, are also represented in a similar 
manner. 

Fig. 3 illustrates the display on screen 24 of windows 54 a-c. which are plan, front and side elevation 
views respective, of the model. In one preferred embodiment, the display utilizes up to four windows to give 
the programmer the ability to observe the lighting effects from these views, and a perspective view from 
another selected point (not shown). 
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Before a portion of the master data base may be displayed in a window, it must be suitably clipped 
against the limits of the window size and then mapped to the display to achieve the desired size. The 
programmer can manipulate the windows, allowing him to move them, overlap them, or resize them. These 
processes do not affect the underlying information from the master data base that is being displayed, but 

5 only the programmer's view of it. As in standard window applications, display management permits the 
programmer to open, close, move, size, scroll, or zoom the windows. Zooming is achieved by introducing a 
scaling factor. If the programmer wishes to zoom in on a particular area, the coordinates are scaled up by a 
suitable factor and clipped against the window limits. 

The programmer is presented with the largest view of the lighting system and stage environment when 

io the window size is defined to surround the set of all objects defined in the lighting system and surrounding 
environment. When the window (e.g., 54a, 54b, or 54c) is defined to be smaller than the scene image, the 
clipping process is performed. The clipping process tests to see which objects are contained within the 
selected window, and then proceeds to clip those objects that lie on the window border and outside of the 
window before the image is mapped to the display screen 24. The portions of the image that remain after 

75 this process are then mapped to the screen 24. When a window (such as 54a, 54b, or 54c) is chosen to be 
smaller than the entire scene, it allows the remaining image to be displayed at a scale that is larger than if 
the entire scene were displayed. This magnified view can be used to show more detail of elements of the 
model. 

The programmer is able to hide .selected objects on the screen in order to reduce the visual clutter in 
20 the graphical view of the model. Objects that are hidden in the graphical view are still maintained in the 
underlying data base and will appear in the spreadsheet view (discussed below) with a column indicating 
their shown or hidden state. Hidden objects will remain hidden until the user commands selected objects to 
be shown again. Although certain objects may be hidden in the display view, they may still serve as targets 
for the lights and as supports for other objects. To hide a selected object, the 'Hide Selected Objects' 
25 command is selected from the 'Objects' menu 44e in Fig. 2e. As mentioned, the object will no longer be 
represented in the graphical view, but its records will be maintained in the underlying data base. 

In order to distinguish objects, the programmer can change the color of a graphical object. The means 
to alter the color is preferably offered in a pull-down menu. The programmer selects the graphical object to 
be "painted" and then selects the "appearance" command in the pull-down menu under "Objects" 44e of 
30 Fig. 2e. This command will cause a deeper level menu to be displayed on the screen that contains the 
alternative colors with which the object can be painted. Upon selecting a color from the list of alternatives, 
the selected object assumes that color. 

TABULAR VIEW OF THE MODEL 

35 

In addition to presenting the programmer with a graphical view of the underlying data base as just 
discussed, the programmer may also display the data in a "spreadsheet" format, as shown in Figs. 4a and 
4b. This is a tabular representation of all of the attributes of the objects defined in a model. The 
spreadsheet can be organized by having the assigned object name or object type (e.g.. a fixture such as a 

40 VL4" U ) appear as the heading of each row in the table. Attribute names such as "Focus" and "Color" can 
appear in the column headings. Each individual cell in the table contains the value of one attribute for a 
particular object. Furthermore, each individual cell can be single-valued (such as Support) or multi-valued 
(such as the height, depth and width components of Dimension). 

The inclusion of spreadsheet columns for each attribute can be under programmer control and thus 

45 removed or added. 

The programmer "hides" a column by clicking on the column heading with mouse 28 and dragging it 
out of the spreadsheet window. Similarly, in order to retrieve a hidden column, the programmer can double 
click on a column divider in the row of column headers or by selecting a column divider and issuing a menu 
command. Either of these actions by the programmer invokes a dialogue message that lists all of the 
so hidden column names. The column(s) that are selected by the programmer from the dialogue message are 
then inserted into the spreadsheet at the location of the column divider that was initially selected. 

If the programmer desires to rearrange the columns in a spreadsheet, he merely selects one or more 
column headers, clicking in one of the selected headings; he then drags the column(s) to the desired 
location and deposits it there by releasing button 29 on mouse 28. The selected columns will be inserted 
55 into the spreadsheet between the two columns separated by the column divider that was initially selected. 

The programmer may be presented with spreadsheet views of the data organized in several ways. The 
preferred embodiment of the invention includes three different spreadsheet arrangements. This embodiment 
creates three versions of the spreadsheets upon the opening of a document or upon the start-up of a new 
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When initially building the model, the programmer can be presented with a menu or listing of building 
blocks or symbolic representations for all of the elements that would likely be placed in the lighting system 
model. This building block menu, similar to a legend or key, is presented as a separate screen, a pull-down 
menu, or a window on a portion of the screen. As shown in Figure 3, when presented with this menu of 

5 building block alternatives, the programmer can designate his building block choice to computer 20 by 
manipulating mouse 28 so cursor 34 points to his selection from among alternatives 66 a-g. Selection of this 
building block is by depressing key or button 29 provided on mouse 28. The selected "icon" will be 
distinguished from non-selected items. If a pull-down menu system is utilized to access the building block 
menu, the programmer must first access the pull-down menu by selecting the menu from menu bar 38. In 

10 the preferred embodiment, the building block menu (or "objects palette") is accessed by selecting menu 
44d in Fig. 2d. Thereafter the programmer "drags" the cursor down to highlight the "show objects palette" 
option. The building block menu then appears in a window on the screen. 

Once the programmer has accessed the list of building blocks he can begin selecting the desired 
objects to be included in the model. A typical legend menu 62 is shown in window 58 of Fig. 3. The legend 

is screen or menu 62 comprises symbolic representations 66 a-g or "icons" that are small pictures that 
represent available elements that can be used in a typical lighting system. The modelling system can be 
programmed with a directory of the symbolic representations of elements that are common in lighting 
systems and the surrounding environments, this directory being stored in computer 20. The directory is 
accessible to the user so that it can be updated by adding or deleting elements as necessary. 

20 Upon the selection of a building block element by the programmer, a record is created in the underlying 
data base in the storage means of computer 20 to store all of the necessary information for that object. 
Preferably, the records are broken down into fields for each attribute of the object that is to be stored. As 
will be discussed below, when the programmer selects an icon the modelling system will know what that 
icon is, and it can create a record in the memory specifically designed for that type of object. The created 

25 record will have fields for every attribute that must be known in order to completely model and program 
each object. The record creation will be discussed with respect to each building block element below. The 
information that is created in the memory records during the creation of the mode! helps to facilitate the cue 
writing process. 

30 LIGHTING INSTRUMENTS 

Icons 66 a-d in the building block menu of Fig. 3 are symbolic representations of various lighting 
instruments that can be utilized in a lighting system. In a preferred embodiment of the invention, each type 
of unique lighting instrument is assigned its own symbolic representation. In the legend menu 62 of Fig. 3. 

35 each of the elements 66 a-d represent different lighting instruments. 

For example, icon 66a represents a standard conventional light that is focussed by hand and whose 
intensity is controlled by an external dimmer. If the programmer clicks on icon 66a to select a conventional 
light for inclusion in the model, a record will be created in the underlying data base with appropriate fields 
and the programmer will be prompted to enter the information that is necessary to define the conventional 
light. Upon selection of a conventional light, the programmer is prompted to enter the channel number 
identifying the light, the symbolic name of the support from which the conventional light will hang and the 
positioning of the light relative to its support. 

This information is stored in the appropriate fields of the record associated with this modelled object. 
Since conventional lights only offer variable intensity control, a field is created in the record to store the 

45 intensity value. The record created upon selection of a conventional light can also include such fields as 
channel number, object type, supporting object, translation (x.y.z translation with respect to its support), 
rotation (x.y.zjptation with respect to its support), focus (pan and tilt values that will not change with the 
recall of cues),-color {value won't change with the recall of cues) and intensity (representation of the value of 
the control signal (0 - 100%) that is sent to the dimmer device to which the luminaire is connected). All of 

so the fields except for intensity are generally defined once the programmer has included and defined the light 
in the model. 

Automated lights can also be assigned unique symbolic representations such as the icons 66 b-d, Fig. 
3. As in the case of a conventional light, the selection of an icon 66b - 66d (representing an automated light) 
establishes a record in computer storage with the appropriate fields and the programmer can be prompted 
55 to enter channel number, support, and position relative to the support associated with the light for entry into 
the associated fields. 

In one embodiment, icon 66b represents a Vari-Lite "VL^B™ " model; 66c represents a Vari-Lite 
"VL3 ru " model, and 66d represents a Vari-Lite "VL4' U " model. Since the modelling system is pro- 
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that stores the orientation of the light with, respect to its support. 
ADDITIONAL MODEL BUILDING BLOCKS 

mathematically define its shape. ftAr . rmar tarnpt _ uch as s j n aers or drummers. 

the appropriate informat.on. development of symbolic 

develops his own representations for numerous stage obiects. AutoCad 

50 descXg the name, dimensions, supporting object, pos.tion and rotation of the model elements. 

SUMMARY 

The foregoing steps are summarized below. 
1 . Selecting and Defining Elements 

The programmer uses the basic building blocks of the legend menu 62 to define the entire model for 
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the lighting system. Upon selection of a building block element by clicking on it the programmer is 
prompted to supply the information needed to define the building block element. 

Alternatively, the programmer can select a building block by entering an alphanumeric character on 
keyboard 30 that is associated with that element. 

As information is retrieved from the programmer it is placed in the appropriate fields of the record 
associated with the selected model object. 

An efficient method of prompting the programmer to retrieve necessary definitional information is by 
means of "dialogue boxes". Typical dialogue boxes are shown in Figs. 6 - 8. The dialogue box is a window 
that can be used to contain text or symbolic representations. 

Once the programmer selects a building block element from legend menu 62, the modelling system will 
recognize the type of object selected (e.g.. truss, target. VL4™, etc.) and can retrieve from memory any 
previously-stored characteristics or other information describing that object. This minimizes the information 
that must be entered by the programmer and maximizes the operating efficiency. 

2. Assigning a Symbolic Name 

The programmer can also use the dialogue box or other data entry means such as keyboard 30 to 
attach a symbolic name to the graphical object that he has selected. During the programming process the 
symbolic names provide the programmer with an easy means for identifying particular targets and elements 
within the lighting system. For changing a defined symbolic name, the programmer can select icon 135 of 
Figs. 7-9, causing a dialogue box to be presented on the screen. The dialogue box will show the 
programmer the symbolic name that is presently associated with the selected object and allow it to be 
updated. The "name" icon 135 can be accessed by means of a pull-down menu or by a palette of tools 
presented in a window on a portion of the display as shown in Fig. 9. 

3. Defining Dimensions 

After selection of a building block, the programmer is prompted to enter its dimensions. In the preferred 
embodiment, the dimensions of the lighting instrument building blocks shown as 66 a - d of Fig. 3 are pre- 
programmed and the programmer will not be prompted for their dimensions. However, when the program- 
mer selects any of building block icons 66 e - g he will be prompted for the dimensions of the selected 
object. The entered information is placed m the appropriate fields in the record created for the model 
object. 

In the preferred embodiment, the programmer can update previously defined dimensions of a selected 
model object by selecting the "dimension icon" 137 of Fig. 9. Upon such selection, a dialogue box will be 
presented with the dimensions of the selected object. The programmer will be able to update the presented 
information. 

4. Defining Supporting Object 

In the preferred embodiment, the programmer is provided with a "support" icon 139 for updating a 
selected graphical object. Upon selecting a graphical object and clicking on the "support" icon 139. a 
dialogue box is presented containing the symbolic name of the object that supports the selected object. 
Thereafter, the programmer will be able to change the supporting object. The "support" icon 139 can be 
accessed by means of a pull-down menu or from a palette of tools 130 presented in a window on a portion 
of the screen. 

5. Defining Positional Information 

In addition to identifying and defining the characteristics for the building block object to be included in 
the model, the programmer also defines the position of the object within the model. After the programmer 
has entered all of the definitional information that has been requested, the object is initially inserted in the 
model in a default location corresponding to the center of the space that supports the object. For example, 
if the object is a target (e.g. a performer) supported by the stage, the target is placed at the center point of 
the stage and at zero rotation with respect to the stage. Thus, the graphical object initially has a translation 
of (0,0.0) and a rotation of (0.0,0) with respect to its support. 

The programmer changes the position of the selected object by clicking on its image, moving the 
objects outline with mouse 28 to the location where the programmer would like to position the object. He 
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then enters this position by releasing button 29. ae in Fln h *» 

When the programmer is positioning a selected object in a multi-view d.splay mode as in Fig. 3. he 
moves the object in one window, such as window 54a (a top or plan view). This process fixes the .position of 
the object with respect to coordinates 'V and "y". The programmer then adjusts the he,ght of the object in 
one of the other windows 54b or 54c to fix the "z" coordinate of the object. Alternatively, using a dialogue 
box, the programmer can numerically define the position of the object by spec.fying its location relative to a 
fixed location that has been defined within the model. 

in the preferred embodiment the programmer is provided with a "dragging" tool 132. F.g. 9. that allows 
him to "drag" a selected object around the screen. The "dragger" can be accessed by means of a pull- 
down menu or from a palette of tools 130 provided in a window on the screen (shown in F,g. 9). Similarly, 
the programmer can also access a "rotating" tool 133 that allows a selected object to be rotated to achieve 
a particular orientation. The "rotating" tool can also be accessed by a pull-down menu or from a palette of 
tools 130 provided in a window on the screen. Alternatively, numerical entry may be made of rotation 
relative to the support or to the master frame of reference. 

These actions by the programmer result in a series of translations and rotations that are reflected in the 
model object's underlying record. The graphical view presents a view of modelled objects of known size 
presented in a window also of known size, therefore a scale can be established to determine the effect of a 
movement in the graphical view on the underlying data base. , innn . , h rMnart tn 

For example if a model object initially has a translation of (0.0.0) and a rotation of (0.0.0) with respect to 
its support and the programmer translates the object 10 units in the x direction. 25 units in the y direction 
and 40 units in "the z direction, then the translation will result in coordinates of (10.25.40) for the obiect. 
Similarly if the programmer rotates the object 90 degrees about the x axis of the supporting object s 
coordinate space, the new rotation of the object with respect to its support will be (90 degrees.0.0). This 
information can then be updated in the fields of the associated underly.ng record. 

Matrix Transformation Solutions 

A complex series of translations and rotations can be resolved by utilizing three-dimensional matrix 
transformations. An ob.ect that initially has translation coordinates of (x, .y, .z, ) will have new coordinates of 
30 (X2,y 2 ,z 2 ) with respect to its support after a translation, where 

x 2 = x. + T„, 
y2 = yi + T y , and 
z 2 = z- + T : , 

where T«. T ¥ . and T 2 are the components of the translation in the x, y, and z directions. This translation is 
represented in matrix form as: 

[x 2 y 2 z 2 l] = [x, y, z, l] 
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Rotation transformations are done in a similar, although more complex manner. It is helpful to utilize 
three separate transformations for rotation about each of the three coordinate axes. If a graphical obiect is 
rotated about the x coordinate axis through an angle e (measured clockwise when looking along the rotation 
axis (x in this instance) toward the origin), the result is achieved with the following matrix transformation: 
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[x 2 y 2 z 2 1] = [x 1 y, z, 1] 
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Rotation about the y axis is given by: 














f y v 1 1 f X* V. 2. 11 
1*2 ^2 2 J 1 '1 1 ■* 


[ COS 


9 0 


sin 


9 


0 1 






CO 


1 


0 






75 














[-sin 


i e o 


cos 


9 


0] 






[0 


0 


0 




1] . 


20 
















And finally, a rotation of angle d about the z coordinate axis is represented by: 
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By utilizing a concatenation process, any number of successive transformations can be represented by 
a single transformation matrix. If a first translation is represented by matrix "T , then a rotation about the x 
35 axis represented by matrix R x . and finally another translation represented by matrix T2, the concatenated 
transformation to represent this sequence that places the new coordinates at (x\ y\ z') is: [x 1 y' z' 1] = [xy 
z 1 ] (T: " R x "T2). The order of operations must be maintained when the transformation matrices are cross 
multiplied together. 

Cross multiplying by the inverse matrix M 1 of a matrix M performs the symmetrically opposite 
40 transformation. The result of this operation is to undo the effect of the transformation with the matrix M. 

Illustration 

To illustrate the addition of a building block to the model, the selection of the stage's building block 
45 element for inclusion in the model and the definition of its necessary characteristic information is discussed 
with respect to the preferred embodiment. The stage is generally one of the first elements to be defined 
and placed in the model. The stage is often the support for numerous objects in the model so many other 
elements are often defined with respect to the stage location. Referring now to Fig. 3, and as discussed in 
general above, the programmer selects the symbolic representation of the stage icon 66e by manipulating 
so cursor 34. Upon selection of stage icon 66e, the processing means of computer 20 recognizes that the 
programmer has selected the symbolic representation for the stage or related platforms. The appropriate 
record and corresponding fields (as discussed above) is established in the data base stored in computer 20. 
The programmer's selection of the stage element from the legend menu triggers a request, generally by 
means of a dialogue box (as shown in Fig. 8), to attach a symbolic name such as "stage" to the object. The 
55 symbolic name facilitates later programming, and allows the programmer to identify the stage when using it 
as a support for other objects. 

The processing means of computer 20 recognizes that the programmer has selected icon 66e. The 
selection of this icon invokes a dialogue message such as that shown in Figure 7, that retrieves the length, 
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width, and height of the element. Thereafter, the programmer is requested to define the stage support, 
which can also be defined by using a dialogue box. The programmer can be presented with a list of all of 
the objects that have been previously defined in the model which may serve as a possible support. 
Generally the appropriate support for the stage will be the "floor" of the venue. 

5 As discussed above, the programmer preferably assigns the position of the stage by using mouse 28 to 

place the graphical representation of the stage in its corresponding position in the model. If the programmer 
has specified a support for the stage (generally the floor of the venue), the symbolic object is placed in the 
center of this graphical space by the modelling system. The programmer then merely has to manipulate the 
symbolic object into its precise location with "dragger" 132. Alternatively, the programmer may use a 

io dialogue box to numerically define the stage position with respect to fixed locations within the venue 
boundaries which have been previously defined and given symbolic names. For example, the programmer 
can define that the "stage" is on the "floor" of the venue centered a particular distance from the "rear wall". 
Once the symbolic representation of the stage has been positioned in the model's graphical image the 
algorithm discussed above determines the x, y, and z translation and rotation of the stage with respect to its 

75 support (the floor). 

The characteristic information defined for this graphical object is stored in the appropriate fields of the 
record that has been created for the stage object. 

The programmer continues developing the model of the lighting system in this manner by selecting and 
defining objects to be included in the model. He proceeds to identify every object to be defined in the 
20 model, specifying the location and characteristics of each. As each object is added, a record is created that 
builds upon the previously entered information. The master data base stores all of the records containing 
parameter information for each of the objects in the lighting system. 

PROGRAMMING A LIGHTING SYSTEM USING THE DEVELOPED MODEL 

25 

As shown above, a graphical representation of the objects of .the lighting system and its venue 
environment is presented on screen 24 as the objects are defined in the model. The modelling system has 
recorded the characteristics, dimensions, and location for each object that was added to the model. The 
completed model and the information that it contains can then be effectively utilized to write "cues" or 
30 snapshots of the current state of the elements involved in creating a particular lighting effect. As previously 
noted, cue data representing the parameters of each element involved in the lighting effect can be written 
and stored, and later recalled to return the lights to the states they were in when the cues were initially 
written. 

A complete cue defines ail of the variable parameters for each light that is necessary to define its 
as lighting attributes and represents what must be transferred to the lights. A partial cue defines only some of 
the parameters but may be combined on playback with current states to create a final effect. The variable 
parameters for a state-of-the art automated light, such as a Vari-Lite model VL4 fM include pan, tilt, color, 
beam size, intensity, edge and gobo. 

40 Selecting Lights to be Defined 

In order to write a cue, the programmer designer must determine which lights need to be activated, 
what their associated targets will be, and the overall lighting effect, static and dynamic, that he would like to 
achieve. Using the representation of the lighting system model displayed on screen 24, the programmer 

45 begins by selecting the lights to be activated and defined. The selection of lights may be done graphically, 
by pointing to the light in the display with the cursor and then pressing a key or button on the input device 
to indicate the selection to the computer 20. Alternatively, as shown in Figs. 10 a-c, the programmer can 
select a light by surrounding it with a marquee. This is done by pointing to the upper left region around the 
light and clicking button 29 on mouse 28 (Fig. 10a); then without releasing the button, dragging mouse 28 to 

so bring the desired light within the highlighting box 50 (Fig. 10b). Finally, once the programmer is satisfied 
that he has selected the appropriate light he can release button 29 on mouse 28 (Fig. 10c). As another 
alternative, the programmer may identify the light to be accessed by entering an alphanumeric symbolic 
name that identifies the light. 

55 Selection of a Group of Lights 

The programmer has the option of selecting an individual light or a group of lights. The selection of a 
group of lights is shown in Figs. 1 1 a-c. In this sequence of figures, the programmer clicks on mouse 28 
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and drags the cursor to include all of the desired lights within the highlighting box 50. The ability to select a 
predefined group of lights is similar to the "Group Select" option that is a common function of the Vari-Lite 
control consoles. This feature simplifies the processes performed by the programmer when he wishes to 
assign the same value for a selected attribute to a group of lights, for example directing a number of lights 
to the same target. Thereafter, the programmer can assign a symbolic name to the group of lights just 
selected. 



Defining Target Parameters (Pan and Tilt) 

The programmer moves the lights to focus on a target by controlling the focus (or pan and tilt) 
parameter of the lights. The programmer can establish the pan and tilt values of any light in either a direct 
or indirect manner. 

The information recorded in the model has established the position of every element within free space. 
This information allows the calculation of the pan and tilt values required to point a particular light at a 
certain target. The pan and tilt values can be calculated by retrieving the location of the particular light and 
the particular target in free space. This has an advantage over methods of programming employed with the 
actual lighting system where the pan and tilt values have to be manually adjusted until the light is focused 
correctly on its target. 

The programmer can specify that the pan and tilt values of any light shall be such that the light is 
focused on a defined target object. Using this "parametric" definition of the pan and tilt values which 
associates the light or lights with a particular target, the modelling system can compute the appropriate 
values. To focus the lights in this manner, the programmer indicates the symbolic name of the appropriate 
target to the computer. The associated target for a light can be retrieved by the programmer by using the 
dialogue box query of the target's symbolic name. In this embodiment, the programmer indicates to the 
modelling system the target that the light should be focussed on. Thereafter, the required pan and tilt values 
are computed. If the resulting tilt is impossible, the programmer is notified by the modelling system. 

If a light is focussed by associating a target, the symbolic name of the target and the calculated pan 
and tilt values can be stored in the light's record. If the target is later moved in the model, the pan and tilt 
values will be correspondingly changed and updated to maintain focus on the target. Again, if the resulting 
tilt is impossible, the programmer is notified. When the cue data is transferred to the control console of the 
lighting system, the pan and tilt values for lights focussed on targets will be transferred as absolute pan and 
tilt values. 

A second method defines the pan and tilt values for the selected lights by entering "absolute" 
numerical values. This is done by selecting the light or lights to be defined and then responding to a 
dialogue box query to enter the pan and tilt values. 

. A third method of defining pan and tilt values for a light is by "preset focus". This method ' as 
implemented .n the Vari-Lite console, focusses the lights to their targets by a dereferenced or indirect 
specification. The programmer selects an arbitrary number of lights, assigns a target to them or enters 
absolute numerical values and then stores this configuration as a preset focus by attaching an alphanumeric 
symbolic name to it which serves to identify it. 

The preset focus position of all presently activated lights can thus be stored in a file and retrieved at 
any time by entering the identifying name. This retrieves for each light the pan and tilt values required to 
focus the light on the desired position. 

When a programmer fixes the pan and tilt values for a cue by means of a preset focus, the symbolic 
name of the preset focus is stored in the cue. The file defining each preset focus is also transferred to the 
control console. When the data is transferred, the pan and tilt values defined in this manner will be identified 
by the associated preset focus symbolic name. When a cue using preset focus is executed in a light the 
light retrieves the proper pan and tilt value by referring to its preset focus record. Prompts for preset 
focuses can be presented to the programmer as a graphical duplicate of the preset focus panel on the Vari- 
Lite console. 

A lighting designer uses several different combinations of beam spread and tilt angle to light a 
performer standing on stage. A 'head shot' uses a narrow beam of light which only illuminates the performer 
from the neck up to the top of the head. A 'head-and-shoulders shot* is similarly from the shoulders up A 
waist shot* .llum.nates the performer from the waist up. A 'full-body shot' illuminates the performer from the 
feet to head. For any given luminaire illuminating a performer, the tilt value and beam size (beam angle) will 
be different for each of these 'shots'. 

By embedding knowledge of the proportional sizes of the various parts of the human body in the model 
the system can calculate the pan/tilt and beam size for each luminaire to achieve a head shot, waist shot. 
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etc. This allows the user of the system to express his requirements by identifying the performer object and 
the desired type of 'shot*, rather than aiming and sizing each luminaire individually. 

Often, a lighting designer will set the pan/tilt values of a group of luminaires to achieve a desired 
arrangement of the light beams in the air, rather than to illuminate a specific target. The designer does this 
by visualizing a certain volume of space through which the beams are to pass, called the 'target volume'. 
The resulting arrangement of beams in the air. or 'look', is a function of a few specific characteristics: the 
positions of the chosen luminaires relative to each other, their positions relative to the target volume, the 
size of the target volume, and the desired arrangement of the beams in the air. Some examples are a 'fan* 
(closely spaced luminaires diverging to pass through a large target volume at evenly spaced intervals), a 
'crossing fan' (widely spaced lights converging onto a small target volume and then diverging), and a 'wall' 
(luminaires with parallel beams). 

By representing target volumes as an object in the system, the user can move or re-size that volume, 
after which the system can recalculate pan/tilt values to maintain the desired look. By embedding 
knowlecge of the characteristics of a fan, wall, etc. in the model, the user of the system can specify a look 
and sc. ^ of its characteristics and the system will fill in the unspecified characteristics. For example, after 
defining a target volume, and specifying a crossing fan of 6 beams from the upstage truss, the system 
could choose 6 evenly-spaced luminaires on that truss which are currently unused and set their pan tilt 
values to achieve the crossing fan. 

PREFERRED METHOD OF CALCULATING PAN AND TILT VALUES 

The preferred method for calculating the pan and tilt values necessary to focus a light on a particular 
target is discussed with respect to Figs. 12 to 18. Fig. 12 shows the coordinate map for a typical automated 
light. This figure shows the x. y. and z axes in the coordinate space of the lamp. The relationship between 
pan and azimuth is also shown. Pan stop 150 serves to limit the rotation of the lamp. As shown in Fig. 13, 
the tilt value of a typical lamp is limited to the range of + 1 35 * to -1 35 • . 

In order to determine the pan and tilt values needed to focus the light at the target, the position of the 
target within the lamp's coordinate space must be determined. This can be performed by determining the 
inverse transform matrix of the lamp within the master frame of reference. Thereafter, the x. y, and z 
coordinates of the target must be determined in the master frame of reference by tracing back the "tree" of 
supports. If the x, y, and z coordinates of the target in the master frame of reference are cross-multiplied by 
the inverse transform of the lamp's matrix, the end result will be the position of the target in the lamp's 
coordinate system. The position of the target relative to the lamp's coordinates is used to obtain the azimuth 
and elevation of the target with respect to the lamp. 

The pan and tilt calculation for the light depends on the azimuth and elevation of the target in the 
coordinate system of the lamp. The azimuth angle of the target is the angular distance of the target from the 
reference axis (x), x>0, in the "horizontal" or x,y plane of the lamp. As shown in Fig. 12. the azimuth angle 
is measured from 0' at the reference axis counter-clockwise through 360' . Similarly, the elevation angle of 
the target is the angular distance of the target from the reference axis (z), z>0. As shown in Fig. 13. the 
elevation angle is measured from 0° at the reference axis clockwise through 135* and counterclockwise 
through -135* . Given the x, y, and z coordinates of the target in the lamp's coordinate space, the azimuth 
and elevation of the target can be determined using trigonometric identities. 

Referring to the flow chart in Fig. 14, the azimuth of the target is obtained by evaluating the x and y 
coordinates of the target in the lamp's coordinate space. The values of x and y are tested against the 
conditions defined in box 160, 164, 168, 172 in the flow chart. The appropriate calculation for each condition 
is defined m the associated boxes 162, 166, 170 and 174. The necessary operation is performed to obtain 
the azimuth (in radians). 

Referring now to Fig. 15, the elevation of the target is similarly obtained by evaluating the x. y. and z 
coordinates of the target in the lamp's coordinate space. The elevation of the target is obtained as a 
function of the target coordinates. As shown in the flow chart, the formula for the elevation calculation is: 

Elevation = Arccos ( z (x 2 + y 2 + z 2 ) 1,2 ) 

The elevation is calculated for the coordinates as long as error condition 182, e.g.. a target point within the 
volume of the light itself, is not satisfied or x, or y or z is nonzero. 

There are two sets of azimuth and elevation values that will correctly focus the light on the same target 
If one set of pan and tilt values for a target is A* and E \ respectively, then the other pair of pan and tilt 
values to focus the light on the same target is (A* 1 180' ) and (-E* ), respectively. 
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The flow chart in Fig. 16 shows a method for determining which pair of azimuth and elevat.on values wil 
ooin the light to the target with minimum yoke movement. The azimuth and elevation (calculated ,n radians) 
a°e convert into degrees in step 192. Additionally, it is necessary to determine the corresponding pan- 
azimuth value (panaz) associated with the present pan setting (pannow) 192. "Panaz" is used .n comparing 
the two pan-azimuths which point to the target and in determining which ,s preferred^ 

In step 194 the two possible pan-azimuths that point at the target are obtained by adding 90 to the 
azimuth (pazl) and subtracting 90' from the azimuth (paz2). The 90' is added or subtracted from the 
calculated azimuth value so that the plane of tilt rotation will pass through the target. Since a pan-azimu th of 
? is definedTn Fig 12 to be pointing along the x axis, a pan-azimuth of 0' puts the ti.t p.ane ,n the plane 
of the y z Is. in this position, the'lamp could point to an azimuth of 90' or 270'. Thus, in order to 
produce a P an-az.muth from an azimuth. 90' must be added to or subtracted from the des.red azimuth. 

Since the range of valid pan-azimuths is limited to 0' through 360" . steps 196 - 202 guarantee that 
"oazl" and "paz2" are maintained in this range (modulo 360*). If pazl is greater than 360* then 360 will 
be subtracted from the value (step 198). For example, a pan-azimuth of 400" is beyond the range of the 
lamp so the value is reduced by 360' to an equivalent pan-azimuth of 40* . Similarly, ,f paz2 is less than 
0- then 360* will be added to it. to keep the pan-azimuth in range (step 202). 

As a result of pan stop 150. pan-azimuths of 0' and 360" represent different positions of the yoke, 
each being on opposite sides of pan stop .50. In steps 204 through 220, it is determined whether the two 
possible pan-az,muths (pazl and P az2) are set to other 0' or 360V If pazl „ equa to 36 0 and panaz 
(the present pan-azimuth setting) is less than 180' (step 216) then pazl should be set to 0 (step , 210 .n 
order to minimize the rotation of the lamp. However, if panaz is equal to 180' (step 208, then each diction 
of rotation is the same, and a "tie-breaker" should determine whether 0' or 360' is used (step 2 2) This 
tie-breaker can be under user control. Steps 214 through 220 show the steps for analyzing paz2^ After these 
steps have been performed, there are two possible solutions for pan-azimuth that are 180' apart. These two 
values are the output of the flow chart shown in Fig. 16. 

The flow chart of Fig. 17 (see also Figs. 18a, b and c) determines which of the two solut-ons should be 
utilized Step 230 determines the delta angular distance that must be traveled by the lamp .n moving from 
the present setting to the new setting for each of the two pan-azimuth values (resulting , in , delta 1 and 
delta2). In step 232. it is determined whether both paths travel the same angular distance. If they do. then 
the tie-breaker determines which pan-azimuth will be used (step 234). 

However, if the paths are not the same, then a determination is made as to which value represents he 
shortest angular distance (which .s the smaller of deltal and delta2). If the angular distance offered by the 
first value (pazD is smaller than the angular distance offered by the second (paz2). then the algorithm 
proceeds to the branch of the flow chart with steps 240. 246 and 248. Step 240 determines whether you 
can get to the new pan-azimuth value from the previous pan-azimuth value without traveling through pan 
stop 150. If so. then the first pan-azimuth value (pazl) is selected and converted to a pan value. The 
corresponding tilt value is chosen based on the "tilt sense" value, where: 

tilt = elevation * tilt sense, (step 250). 

If step 240 determines that the light cannot travel from the previous pan-azimuth value to the new pan- 
azimuth value without going through the pan stop 150. then the longer distance (paz2) should be chosen. 
Steps 238. 242 and 244 proceed from step 236 when the angular distance to be traveled is shorter for the 
paz2 value. These steps are evaluated in the same manner as steps 240, 246 and 248. 

Since tilt values are limited to the range of ♦ 135' and -135' . if an impossible tilt value results then 
there will be no solution and an error condition will arise. 

Example 

The pan and tilt computation is discussed below with respect to the position of a target in a lamp's 
coordinate system. In order to illustrate, a target having coordinates of (20.20.45) in the lamp s coordinate 
system is discussed. Proceeding initially to the steps shown in Fig. 14. the x and y coordinates o the target 
are both positive (condition of Step 160), therefore the calculation results in an Azimuth equal to the inverse 
tangent (arctan) of (20/20) or the arctan of 1. This results in an azimuth value of »/4 radians (or 45 degrees). 

Thereafter, the elevation is calculated according to the method shown in Fig. 15. Since the error 
condition of Step 180 is not satisfied, the following elevation computation is performed in Step 184. 

Elevation = Arccos (45/(20 2 + 20 2 + 45 2 )" 2 )- 
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An elevation of approximately *. 5.6 radians (or + 32.2 degrees) results 

As discussed above, the algorithm in Fig. 16 determines which of the pair of possible oan and tilt »,!...< 
w.., pent the light to the target with the least amount of movement. S^ .STSg^e^^SZ 
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,e sirr r^c^pS^Ci'S :r r^rr based ° n 

degrees, m order to maintain the value between 0 and 360 degrees suiting .n a value of 315 

Here, pazl is not equal to 360 degrees (Step 204) and paz2 is not equal to 0 decrees (Steo 21 4> 

Th^ 6 ^ 32 'I' 2 rePreSem ,he «"° P0SSib ' e values of Pan-a,imu,h (and are iS^iS?^) 
These two values are the output of the Fig. 16 flow chart aegrees apart). 

i^lT™,? F ' 9 ' V determines whlch of the two solutions just determined should be utilized Steo 
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The programmer can establish "model cues" to allow for the r^rr^finn rt # a 

Defining Beam Characteristics 

Similar.y. the programmer may define the remaining beam characteristics of a complex automated 
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lighting system (such as color, beam size, intensity, edge and gobo) in a number of ways. One alternative is 
to define the parameters in an "absolute" manner. As an illustration, if the programmer wishes to define the 
intensity of the lights in an "absolute" manner, he can specify that all of the selected lights should have an 
absolute intensity value, for example an intensity of 65%. Parameter data that has been defined in an 

5 "absolute" manner will not be automatically updated as alterations are made in the model- 
Alternatively, the programmer can define these parameters in a "parametric" manner, which allows the 
programmer to assign parameter values with respect to a particular target. To illustrate, if the programmer 
defines the intensity in a "parametric" manner, he specifies that all of the lights which are focused on a 
particular target or are in a particular color or are mounted on a particular truss, shall have a particular 

jo intensity, for example an intensity of 65%. The target or color or truss may be chosen by utilizing a 
dialogue box to enter the symbolic name that identifies it or by selecting it with the input device as 
discussed above. 

In another variation, the programmer specifies that all of the lights focused on a particular target should 
be adjusted to produce a desired intensity at the target. The system calculates the required intensity, for 
ts each light so that for the combined effect of all the lights focused on the target achieves the desired lighting 
level. 

Defining Color 

20 When theprogrammer is specifying the color for a particular light or group of lights, he may select the 
color in a number of ways. Once the programmer has selected a light to be defined as part of the model, 
the particular type of light that has been selected is known. Correspondingly, the color palette appropriate 
for that type of lighting instrument can be presented to the programmer in a dialogue box. The programmer 
can use the palette to select the color. In this manner, the programmer can review the available colors and 

25 select the desired one. The color palette can be presented in a familiar format such as by the chromaticity 
triangle. Alternatively, the programmer may wish to enter an alphanumeric name that has been associated 
with a color he desires. As another possibility, the programmer may define color in an absolute manner by 
directly controlling the positions of the color filtration elements in the lighting unit. This is obtained by 
defining the position of the color wheels {for example in a VL2B rw ), or by defining the angles for each of 

30 the three color filters (magenta, amber, blue) of a lighting unit such as in a VL4 7U . 

In a preferred embodiment of the invention, the programmer is able to assign the color of a lighting 
instrument by establishing "preset colors", similar to the control offered by the Vari-Lite console. Typically 
the color produced by a lighting instrument can be defined with "standard" colors (assigned by the 
manufacturer) as well as "custom" and "open" colors (assigned by the programmer). When the color is 

35 defined by using "custom", the preset color identifier is stored in the cue. The programmer defines 
"custom" colors indirectly, by means of dereferenced colors. The color that will be recalled when the cue is 
initiated is the color that is programmed into the "custom" palette at the time when the preset color is 
stored. When the color of lighting instruments is defined by means of "open" colors, they will be assigned 
an absolute color. 

40 The color of a selected light can be specified by a prompt which duplicates the Preset Color controls of 
a Vari-Lite control console. In that console, the action of pressing a preset color button on a console sets 
the currently selected lights to the color assigned to that preset color. 

Gobo Selection 

45 

Similarly, if the lighting instrument being defined achieves beam modification by means of a gobo, the 
data base can maintain tables of the available gobo selections for each lighting instrument being used and 
the gobo selected. When selecting the gobo to be used to project a desired beam configuration, the 
programmer can be presented with a graphical representation containing all of the possibilities. The 
so programmer then merely selects the gobo that he would like to use to achieve the desired effect from the 
alternatives presented. Alternatively, the programmer can specify his gobo selection by indicating the stop 
position of the gobo wheel. 

When defining other beam characteristics, such as beam size, intensity, and edge the programmer may 
specify these values by entering the desired values in a dialogue box. 

55 

STORING CUE DATA 

Once the programmer has obtained the desired lighting effect for a particular cue by manipulating the 
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oarameter values he can store the parameter information -as a cue for later retneva E ach cue is , assigned 
^SZ^Z fwmB for identification, which ,s generally a number system that follows the sequence of 
me Performance The cue data may be stored in the memory of computer 20 and/or an external storage 
med? such as a diskette Cue data may be formatted for transfer to and use by the actual hght.ng system 
Sussed further ber o w) when the cue is stored in the memory of the actua. lighting system ,t may be 
recall by entering its assoaated number. Once a cue is initiated by the programmer ,n the ^><^ 
system the lights will adopt the state that their corresponding model objects were .n dunng the simu.at.on 

^r'S 9 :^' stored through an interactive process. A preferred embodiment for the 
process of writing and storing cues is illustrated in Fig. 19. The cue writing menu 70 shown in , *g _l can 
£ e presented in a window or accessed by means of a pull-down menu. After the programmer h» oblamed 
^Snq effect that he desires by manipulating the lighting attributes according to methods d, cussed 
above he c a r S o e the lighting effect as a particular cue number by entering the number ,n the cue 
above, he can sio e y a jn ig Similarly _ lf tne programmer 

Th re^S atghting' ie°ct Z Z Len previously stored as a cue. he may do ^ by ending the 
desired cue number in the cue number window 72 and clicking on the recall or rcl .con 78. The screen 
w.ll automatically be updated to reflect the lighting effect of the selected cue. 

GRAPHICAL REPRESENTATION OF LIGHTING EFFECTS 

During the modelling process graphics display 24 presents the programmer with > a vie .w of the 
information stored in the underlying master data base. Similarly, as the programmer programs the lights, 
ZZ 2 i u Szed to show the programmer the effect that each parameter variation has upon the lighting 
svstem As shown in Fig. 20. graphics display 24 provides a representation of the l.ghtmg effect as the 
Xramm r varies and de.inesthe parameters for each „ght. The simulation displays the P£ «d 
Bit by showing a beam of light that originates at each light source and terminates at the assoaated target. In 
this case each of the lighting instruments 101-1 10 are focussed upon the singer 117. 

A color graph, s display allows the beam of light to be displayed in the color that has been se ectec by 
the prog ammer The programmer can also get an accurate view of the effects of beam s.ze. as the beam 
o, light LTTpread according to the programmed value. The underlying system aide d b> ^ , gr ap , s 
feature allows an entire light show to be programmed without requiring the V^**^™*^ 
or the liqhts The programmer is able to see the lighting effects as a function of the parameter data and I as 
a resul P ogramm,ng 9 methods are not limited by the ability of the programmer to imagine the gh ng 
effects The programmer observes where the lights are focussed. and can v.suahze how the l.ghtmg 
attributes of each individual light combine to produce the overall lighting effect. „„„,„.„ 

While programming a particular cue. the programmer can observe the effects of any parameter changes 
on the overalf lighting effect. If the programmer were to recall a previously recorded cue from , m «o nr. 
according to methods discussed above, the model would be graphically represented on the display 24 w.th 
fheTgting effect as a function of the stored cue data. If the programmer modifies a stored parameter, such 
as color, the representation would show the programmer the results of such changes. 

UPDATING THE DEVELOPED MODEL 

Generally it would be very difficult to develop a single model that accurately reflects the features of 
everf venue in which the performance tour will operate Each venue has its own unique attributes and 
d mens 2 s which may need to be reflected in the mode. ,n order ,o obtain accurate cue dat. Correspond 
ingly if the programmer has written his cue data such that certain parameters depend on an accurate 
representation of the venue boundaries, stage size. etc. then the programmer must ensure that t h ,s 
nformation is correctly defined in the model. The programmer can update the stored b J 
, selecting the graphical representation of the object using the input dev,ce, as discussed above, or by 
Tn er ^g the alphanumeric name that is associated with it. Upon doing either of these, the programmer ,s 
presented with the information that has been previously defined for the se.ected ob.ect. The programmer 
may then update any of the information in the model that does not conform to the actual ™ f ™««- 

Similarly, if the physical placement or characteristics of any of the elements of the lighting assembly 
, and stege environment within the venue do not coincide with the way they were defined m the model the 
p^ogrTmmer must update this information. If the position or other charactenstic data of 
be revised the programmer selects the item to be updated from the model and then updates the 
information'p eviously entered in the model. These tasks may be done graphically, by means of a dialogue 
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entry, or using the spreadsheet mode as discussed above. As the programmer modifies the model, e.g.. as 
he moves an object to a new location on the display screen, the new information is reflected by a change of 
values in the underlying corresponding data base. 

Any needed update to the model can be easily executed in order to incorporate new information into 
the model to accurately reflect the actual lighting system and stage environment. 

UPDATE OF PREVIOUSLY WRITTEN CUE INFORMATION 

Furthermore, the parameter data stored as cues may need to be updated if the sequence of events in 
the performance has been changed, or the location of targets in certain cues is modified. As discussed 
above, the programmer can update cue data by retrieving the cue from memory by indicating the cue to be 
retrieved and clicking on the "RCL" icon shown in window 70 of Fig. 19. Thereafter, the previously stored 
lighting effect as a function of the stored parameters can be displayed on the screen and updated. The 
programmer can alter any parameter that does not conform to the actual situation. If a target location for the 
cue has been relocated, the programmer can select the target as discussed above and "drag" it to its new 
location. As an alternative the programmer may also update any target information by interacting with the 
modelling system by means of a dialogue box. 

DATA TRANSFER 

As suggested in Figure 1. the cue data that is written by the programming system to define a lighting 
effect is translated into data that may be transferred directly to a lighting control console or to local lighting 
instruments. (In the latter case, the modelling computer is serving as the console.) The syntax of the data 
should be mutually interpretable by the modelling and programming system disclosed herein and by the 
conventional control consoles and lighting instruments. In addition to being machine readable, it is 
preferrable that the data format be human readable as well. A readable textual representation of the data 
makes the debugging process easier. The modelling and programming tool, and the actual lighting system 
should be able to read and write in this data format to facilitate bidirectional communication. Additionally, 
error handling capabilities allow the system to be fault tolerant. 

The data format also provides a uniform method for storing all of the cue information that is necessary 
for each lamp. The file can be arranged in a manner that lists the name and location of each lamp, and 
stores the parameter data for every cue in the show. 

Using the bidirectionality facilitated by this data format, the user can transfer data which has been 
created or modified in the control console back into the modelling system for subsequent display and 
further modification. 

REAL-TIME RENDERING 

The data that has been stored by the modelling system may be processed by a rendering device in 
order to generate photo-realistic images that represent the stored data. This service is provided for example 
by the use of a RenderMan program. See "The RenderMan Interface" published by Pixar, 3240 Kerner 
Blvd., San Rafael, CA 94901. This document details the services available from a RenderMan rendering 
program. 

These images can be utilized to depict what the lighting effect is going to look like. Further, utilizing 
computer animation techniques to project a continuous sequence of cues at speeds which approach real- 
time, the viewer can observe chases and the dynamics of the lighting show. The quality of the simulation is 
a function of the sophistication of the hardware and software platforms that are selected to do the rendering. 
The sophistication of the image that is available to an average user will improve as the costs and 
processing power of available systems improve. The technology is moving closer to lower cost systems 
with excellent simulation capabilities. Ultimately these rendering devices can be used by lighting designers 
to present a client with a completely simulated performance complete with all of the lighting effects. 

Using speaker-independent voice recognition systems with large vocabularies such as those sold by 
Kurzweil Applied Intelligence of Waltham, MA, the modelling system can provide spoken access to any of 
its capabilities. 

VIRTUAL CONSOLE / VIRTUAL REALITY 

With equipment developed by VPL, 656 Bair Island Road, Redwood City. CA, 94063. the 2-D display 
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screen of the modelling system can be replaced by a 3-D display in which the user is represented by a 
"virtual self", allowing him to "enter" the simulation and interact with it. 

The user can control his "virtual self" by means of a Data-Glove, which is a device to measure the 
degree of bend of the joints of each finger, and the movement and location in space of the fingers and the 
5 hand. Information from the Data-Glove is transmitted to the host computer and represents what the hand is 
doing at any moment. 

The program uses this input to control the user's "virtual self" which can appear to pick up and 
manipulate virtual objects in the model. Movement of objects in the model can now be accomplished by the 
user causing his "virtual self" to pick up the object and transport it to its new location. For example, the 
/o user can grab a light beam and move it, thereby refocussing that luminaire on a new target. 

Additionally the user can be presented with a virtual control console with which his "self" can interact. 
By manipulating the controls of this virtual console as he would a real console, the user has an additional 
method of controlling the lights and lighting effects. Likewise, the user can write, store and recall cues as he 
would using a real console. 

75 

DISTRIBUTION OF FUNCTIONS OF OUT OF SERVICE LIGHTS 

The modelling system offers the further feature of being able to distribute the functions for any lights 
that go out of service. The functions of these out of service lights can be transferred to other lights that are 
20 in the lighting system. The lighting system can sense when a particular light has gone out of service. 
Additionally, the lighting system knows the associated targets and lighting parameters for each cue. 
Correspondingly, the functions of a light may be redistributed to alternate or backup lights when a light 
cannot perform the functions. 

25 INTEGRATED MODELLING SYSTEM 

In some cases the modelling computer can be integrated with the console and share tasks with the 
controller, including in certain circumstances, the direct control of the lights. 

30 Claims 

1. A system for modelling a lighting production including the characteristics of the production site and the 
lighting scenes produced by the lighting console and the lighting instruments without requiring access 
to the site, console or lights, comprising a computing system having data entry means, a processor, 

35 storage means, a monitor and a graphics generating program, said modelling system including: 

(1) means for entering data describing relevant parameters of the lighting site including lighting 
targets; 

(2) means for receiving data identifying the selection of the lighting instruments to be operational in 
the production of said lighting designs; 

40 (3) means for receiving data describing the location of said selected fighting instruments; 

(4) means for receiving data describing values of the lighting parameters associated with each of 
said selected lighting instruments; 

(5) means for computing from said site, light selection, light location and value data, mathematically 
correct three dimensional representations of the desired aggregate lighting designs; 

45 (6) means for displaying certain of said representations on said monitor; and 

(7) means for configuring the results of said computations in a form suitable for ultimate use by said 
actual lighting instruments. 

2. The system according to claim 1 in which said data receiving means include means displayed on said 
so monitor prompting the entry of said data. 

3. The system according to claim t including means for computing the relationships among the received 
data such that changes in certain of said data produce related changes in data dependent thereon. 

55 4. A system as defined in claim 1 including means for generating at least one spreadsheet generally 
conforming to the type employed by a lighting designer in describing the actual lighting production. 

5. A system as defined in claim 1 wherein said means for computing said representations include means 
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for simultaneously generating and displaying views of said lighting scenes from different perspectives, 

6. A system as defined in claim 1 in which said means for computing said representations includes means 
for displaying the contributions of the site, light location and light parameter values to the aggregate 

5 lighting scene. 

7. A system as defined in claim 1 including means for computing pan and tilt values as a function of 
lighting instrument location and target position. 

w 8. A system as defined in claim 1 including means for organizing the components of said site parameters 
on a hierarchical basis. 

9. A system as defined in claim 1 including means for generating menus, dialog boxes and icons to 
facilitate entering of said data. 

75 

10. The system according to claim 1 in which said representations constitute cues which can be stored and 
recalled at will, 

11. A system according to claim 1 in which lighting parameters can be specified in terms of target 
20 positions. 

12. A system according to claim 1 in which said lighting targets include representations of performers and 
wherein lighting parameter data can be defined and processed to illuminate portions of said performer. 

25 13. A system according to claim 1 including means for representing target volume as an object in the 
system and wherein said volume can be moved and sized, producing corresponding adjustments in 
associated lighting parameters. 

14. A system according to claim 1 in which said means for entering site data includes means for 
30 generating a plurality of orthogonal views on said monitor to display all the positional coordinates of 

objects in said site. 

15. A system according to claim 1 in which the output of said computing system is linked to said console 
for the exchange of lighting parameters. 

35 

16. A system according to claim 1 in which said modelling system includes means for displaying model 
data in a variety of selectable formats. 

17. A system according to claim 1 in which said modelling system includes means for receiving from said 
40 console, data describing actual productions for review and modification by said modelling system. 

18. A system according to claim 1 in which said modelling system includes means for controlling said 
lighting instruments from said modelling system. 

45 19. A system according to claim 1 in which said modelling system includes means for specifying the 
relation between model objects. 

20. A system according to claim t in which said modelling system includes means for simulating dynamic 
aspects of said lighting scenes. 

50 

21. A method for modelling a lighting production including the production site and the lighting designs 
produced by the lighting console and lighting instruments, said modelling method employing a 
computing system having a graphic display program, data entry means, data processing means 
including a graphic generating program, and a monitor; said method comprising the steps of 

55 (1) entering data into said computing system describing relevant characteristics of said lighting site 

including lighting targets; 

(2) entering data into said computing system identifying the lighting instruments to be involved in a 
scene; 
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(3) generating a display on said monitor representative of said described site; 

(4) entering in said computing system, data related to the positional relationship of said selected 
instruments to said lighting site; 

(5) generating on said monitor a display of said site with said selected instruments showing the 
positions thereof; 

(6) entering in said computing system data, describing the lighting parameters of each of said 
selected lighting instruments including, where desired, lighting beam color and beam direction; 

(7) generating for evaluation a display on said monitor simulating the aggregate lighting effects 
produced by said site, said lighting instrument selection, said positioning and said parameter 
adjustment; and 

(8) repeating the foregoing steps as necessary until a desired display is achieved. 

22. The method according to claim 21 including the step of generating displays on said monitor prompting 
the entry of said data and minimizing the entry of illegal data. 

23. The method according to claim 21 including computing the relationships among the received data such 
that changes in certain of said data produce related changes in data dependent thereon. 

24. A method according to claim 21 including generating spreadsheets of adjustable format including at 
least one spreadsheet generally conforming to the type employed by a lighting designer in describing 
the actual lighting production. 

25- A method as defined in claim 21 including the step of simultaneously generating and displaying views 
of said lighting scenes from different perspectives. 

26. A method as defined in claim 21 in which said simulating step includes displaying the contributions of 
the site, light location and light parameter values to the aggregate lighting scene. 

27. A method as defined in claim 21 including computing pan and tilt values as a function of lighting 
instrument location and target position. 

28. A method as defined in claim 21 including organizing the descriptions of said site on a hierarchical 
basis. 

29. A method as defined in claim 21 including generating menus, dialog boxes and icons to facilitate 
entering of said data. 

30. The method according to claim 21 in which said aggregate lighting effects constitute cues which can be 
stored and recalled at will. 

31. A method according to claim 21 in which lighting parameters can be specified in terms of target 
positions. 

32. A method according to claim 21 in which said lighting targets include representations of performers and 
wherein lighting parameter data are defined and processed to illuminate portions of said performer. 

33. A method according to claim 21 including generating data representing target volume as an object in 
the system and producing corresponding adjustments in associated lighting parameters when said 
volume is moved or sized. 

34. A method according to claim 21 in which said site display includes a plurality of orthogonal views on 
said monitor to display all the positional coordinates of objects in said site. 

35. A method according to claim 21 including the exchange of lighting scene parameters between said 
modelling system and and said lighting system. 

36. A method according to claim 21 including displaying model data in a variety of selectable formats. 
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37. A method according to claim 21 including receiving from said console, data describing actual 
productions for review and modification by said modelling system. 

38. A method according to claim 21 including controlling said lighting instruments from said modelling 
system 

39. A method according to claim 21 including specifying the relation between model objects. 

40. A method according to claim 21 including simulating dynamic aspects of said lighting scenes. 
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